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ABSTRACT 



A tool for programming non- volatile memory is embedded 
in the form of an object in a programmable controller 
module, and can be used to transfer a firmware program to 
a plurality of different modules connected by a common 
network. The tool can be placed in any type of module, and 
can be used to transfer a firmware program to any type of 
module, regardless whether the two module types are the 
same or different types. The firmware program is received in 
a first module from a user interface by way of a communi- 
cation link, which may be relatively slow. The object is 
embedded in the first module and has a plurality of services 
and attributes which are adapted for transferring the firm- 
ware program to a plurality of target modules. The first 
module and the plurality of target modules are connected by 
way of the common network, which is preferably a high 
speed network. Thus, the time required to transfer the 
firmware program to the plurality of target modules is 
nominal once the firmware program is received in the first 
module. Advantageously, the present invention provides a 
system which can rapidly program a plurality of modules 
having non-volatile memory, which is usable both during 
production and in the field, and which can program a 
plurality of different types of modules regardless of the types 
of communication ports disposed on the fronts of the mod- 
ules. 

17 Claims, 5 Drawing Sheets 
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EMBEDDED NON-VOLATILE communication ports inherently require different hardware 

PROGRAMMING TOOL aQ d software configurations on the PC for each of the 

different types of modules. 

FIELD OF THE INVENTION Second, this approach is very slow. The communication 

TTie present invention generally relates to tools for pro- 5 P°? , dis P oscd 1 ? 1 ? ** fron \° f m ° St typ6S ,° f l ? odules is 3 

■ i . i — ~ ^ ~ r, n serial port, which is very slow. For example, the program- 

gramming non-volatile memory, and more specifically f. r i r ™ r> \i ^ • 

& . 4 4 & ... y . . i . i • mmg time for a typical PLC processor module using an 

relates to a non-volatde memory programming tool which is RS .| 32 ^ coni £ ction ^ OI f the order of about , w * nty 

embedded in a module of a programmable controller. mimUes ^ ^ modules have an Ewerae , connection 

DESCRIPTION OF RELATED ART ao anc * l ^ us ^ ave l° wer programming times, these modules are 

very much in the minority. 

Programmable controller systems are known for control- what fe needed is a non . vo i ati i e memory program- 
ling industrial processes. A typical programmable controller ming tool which can 5e used ^ a plura ii ty of different 
system comprises a processor module, for example a PLC® types of moduleSj rega rdless of the type of communication 
processor module, and a plurality of other programmable port 0D the front of the module , and which can program 
controller modules. The other modules could include, for non-volatile memory at high speeds, 
example, one or more Ethernet® modules, DHRIO (Data 

Highway™ Remote Input/Output) modules, CNB SUMMARY OF THE INVENTION 

(ControlNet™ Bridge) modules, analog modules, and/or a A production object for an object-oriented programming 

plurality of other types of modules. (Herein, for language is disclosed. The production object is disposed in 

convenience, trademarks are designated as such only upon a first module and has a plurality of services and a plurality 

their first occurrence.) The PLC processor module and the of attributes which are adapted for transferring a program 

plurality of other modules are disposed in a rack and from the first module to a second module over a common 

networked by a common backplane. network. 

Programmable controllers are usually programmed using 25 A programmable controller system is also disclosed. The 
an object-oriented programming language which is formed programmable controller system includes a backplane, a first 
by a set of objects which model real-world problems. The module, and a second module. The first and second modules 
objects each provide a set of services and each have one or are disposed in the backplane and are linked by the back- 
more attributes which define the parameters of the object or plane. The first module is adapted for receiving a firmware 
the services it provides. The objects interact through a 3Q program. The first module has a programming tool disposed 
message-based interface which allows them to access each therein which is adapted for transferring the firmware pro- 
other's services without having to understand each other's gram from the first module to the second module over the 
internal characteristics. Different objects are implemented in backplane. Preferably, the programming tool is in the form 
different modules, and the different objects give the modules of a production object as described above, 
their unique functionality. 35 A method of transferring a program to a plurality of target 

The objects are implemented in the firmware of the PLC modules is also disclosed. According to the method, a 

processor module and the other modules. The firmware is programmable controller system comprising a first module 

programmed into the modules during production and is often and the plurality of target modules is provided. The pro- 

later updated. According to present methods, the program- grammable controller system is programmable with an 

ming of a module during production occurs according to the 40 object-oriented programming language, and the first module 

following two-step process. First, automatic test equipment and the plurality of target modules are commonly disposed 

loads boot code (a small amount of code on the order of in a common backplane. 

32-64 kilobytes) directly into non-volatile memory (e.g., Then, a first allocate request message is sent to a memory 
Flash memory or EEPROM) using specialized in -circuit test object in the first module. The memory object has a plurality 
equipment. 45 of services and a plurality of attributes which are adapted for 
Second, a non -volatile memory programming tool is then managing memory of the first module. Responsive to the 
used to load the remainder of the firmware (a large amount first allocate request message, the memory object allocates 
of code on the order of 150-500 kilobytes). The boot code a first memory block in the memory of the first module. A 
loaded during the first step contains enough functionality to script file is then transferred from a user interface to the first 
program the non-volatile memory with the remainder of the 50 memory block. The script file defines parameters for trans- 
firmware received from the programming tool. The pro- ferring the firmware program to the plurality of target 
gramming tool resides on a personal computer (PC) and modules. 

connects to an individual module by way of a communica- Also, a second allocate request message is sent to the 

tion port disposed on the front of the module. The program- memory object in the first module. Responsive to the second 

ming tool establishes a connection (e.g., usually a serial 55 allocate request message, the memory object allocates a 

connection) with the module, and then downloads the firm- second memory block in the memory of the first module, 

ware to the module by way of the communication port. For Then, a data file is transferred from the user interface to the 

simplicity, it is desired that the same programming tool be second memory block. The data file contains the firmware 

usable both for production and for field updates; thus, field program. 

updates also occur in accordance with the second part of this 60 Next, a create request message is sent to a production 
process. object. The production object has a plurality of services and 
This approach suffers at least two drawbacks. First, a a plurality of attributes which are adapted for transferring 
separate and unique programming tool is required for each the firmware program from the first module to the plurality 
of the different types of modules. Different types of modules of target modules. The production object is disposed in the 
have different types of communication ports, depending on 65 first module. The create request message causes a new 
the function which the particular type of module is designed instance of the production object to be created for transfer- 
to perform. The unique aspects of the different types of ring the firmware program to the plurality of target modules. 
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Also, script and data pointer attributes are set. The script first to FIG. 1, the system comprises a personal computer 

and data pointer attributes point to the first and second (PC) 20 connected to a PLC system 30 by way of an RS-232 
memory blocks, respectively. The script and data pointer link 50. 

attributes are two of the plurality of attributes of the pro- As is conventional, the PC 20 comprises a keyboard 22 

duction object. 5 and a mouse 24 for accepting user commands, a floppy disk 

Finally, the production object is invoked and the firmware drive 26 for accepting data and other information via floppy 

program is transferred from the first module to the plurality disk, and a display 28 for communicating to the user. The PC 

of target modules over the common backplane. This trans- 20 also comprises a network connection 52 for alternatively 

ferring step is performed by the production object. accepting data and/or user commands from a network (not 

Advantageously, the preferred embodiment of the present 10 illustrated), 
invention provides a rapid way of programming modules The PLC system 30 comprises a PLC processor module 
having non- volatile memory. Unlike current systems, the 32 and a plurality of other modules 34-42. The other 
programming tool is in the form of an embedded object and modules 34-42 could include, for example, one or more 
is located internally and not externally to the programmable Ethernet modules, DHRIO modules, CNB modules, analog 
controller system. As a result, it is possible to transfer the 15 modules, PLC processor modules and/or a plurality of other 
firmware program to the production object just once (e.g., types of modules. The modules are disposed in a rack (not 
over a serial link), and then the production object can illustrated) and are networked by way of a common back- 
transfer the firmware program to a virtually unlimited num- plane 54 (see FIG. 2). 

ber of target modules over a high-speed network connection. At least one of the modules 34^12 is a target module 
Thus, the amount of time required to program a plurality of 20 which has been targeted as a module that is to be updated, 

modules is drastically reduced. Further, the preferred Whether all of the modules are target modules depends on 

embodiment of the present invention is usable both during how the system 10 is being used. If the system 10 is being 

production and in the field. It is not necessary to have two use d to perform field updates, then it may be the case that 

different systems for programming modules depending on only one of the modules 34-42 is a target module. On the 

when the programming takes place. Moreover, the present 25 other hand, if the system 10 is being used for programming 

invention minimizes the downtime of modules when updat- the modules during production, then the modules 34-42 

ing occurs, even when only a single module is updated. WO uld normally all be target modules and would normally 

Finally, the preferred embodiment of the present invention all be the same type of module. 

provides a single tool which can be used to program a In principICj the only difference ^twcen programming 

plurality of different modules, regardless of the types of during production and updating in the field is the number of 

communication ports disposed on the fronts of the modules. modules thal are programmed or updated. Thus, the terms 

Other objects, features, and advantages of the present "programming" and "updating" (and other forms of the 

invention will become apparent to those skilled in the art same words) are used interchangeably herein. For simplicity, 

from the following detailed description and accompanying the discussion herein initially focuses on the programming 

drawings. It should be understood, however, that the detailed 0 f a single target module 42. 

description and specific examples, while indicating pre- Referring now to FIGS. 2A-2B, a more detailed func- 

ferred embodiments of the present invention, are given by tional block diagram of the programming system 10 is 

way of illustration and not limitation. Many modifications ii lustr a t ed. The main functional components of the system 

and changes within the scope of the present invention may 10 are the pc 20 (which ides a ^ imerface ^ which 

be made without departing from the spirit thereof, and the stores firmware rev isions), the PLC processor module 32 

mvention includes all such modifications. (which pe rforms the update) and the target module 42 

BRIEF DESCRIPTION OF THE DRAWINGS ( which receives the update). 

* e j „ , l j . , c . . ... More specifically, the PC 20 also comprises a user inter- 

A preferred exemplary embodiment of the invention is f a * i u „ c 

:iu tct „ ioA • tUa Z i a u- u i i 45 face 21 and a firmware library 23. The user interface 21 

illustrated in the accompanying drawings in which like r «, L • r <• r-... 

— i f 1*1 _* XT u * j • performs three basic functions. First, the user interface 21 

reference numerals reference like parts throughout, and in ' , , ... n ... 

wn j c k- ° enables a user to introduce a new firmware revision into the 

^ ' ^ .„ , , firmware library 23 of the PC 20, e.g., by way of the disk 

FIG. 1 illustrates a system for programming non-volatile drive 26 or the network connection 52. Each time a new 

memory in accordance with the present invention; 5Q firmware revision ^ generated) the firmware revision is 

FIGS. 2A-2B illustrate a functional block diagram of a loaded into the firmware library 23, which then preferably 

non-volatile memory programming system in accordance stores the entire set of firmware revisions for each of the 

with the present invention; different types of modules used by the PLC system 30. 

FIG. 3 illustrates a programming process in accordance Second, the user interface 21 also allows the user to select 

with the present invention; 55 a firmware revision to be loaded into the target module 42. 

FIG. 4 illustrates in greater detail the step of transferring Normally, the user selects the most recent firmware revision 

the firmware update from a PLC processor module to a to be loaded into the target module 42. Sometimes, however, 

target module in the programming process illustrated in FIG. the user may wish to enter a previous firmware revision into 

3, in accordance with the present invention; and the target module 42, for example, for purposes of perform- 

FIGS. 5A-5C illustrate an encryption/decryption system «0 ing testing. Finally, the user interface 21 transfers the 

usable in conjunction with the system and process of FIGS. selected firmware revision to the PLC processor module 32, 

1-4, in accordance with the present invention. which then communicates the firmware revision to the target 

module 42, as described in greater detail below. 

DE J^f ™SS!1S^ E Eacb firmware revisi0Q a data file and a 

PREFERRED EMBODIMENT 65 file ^ dala file comajns lhe updaled firmware> and the 

Referring now to FIGS. 1 and 2A-2B, a system 10 for script file contains parameters that define how the firmware 

programming non-volatile memory is illustrated. Referring revision should be performed. The preferred script file 
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format includes the fields illustrated in Table 1. The mean- 
ings the fields are also described in Table 1 and are further 
clarified by the discussion below. It should be understood, of 
course, that the script file could contain more, less, and/or 
entirely different fields, depending on the application. 

TABLE 1 



Exemplary entries of a preferred script file. 
FIELD NAME MEANING 



Field Entries Common to all Updates 

NumberUpdates Indicates the number of updates contained in the 

script file 

Numberldentities Indicates the number of entries in the "Identity N" 

table (described below) 
Identity N - [1 . . . n] Implements a table, each entry in the table lists 

identification parameters (vendor name, etc.) of 

a specific product type with which the script file 

is compatible 

ConncctionType Flag which indicates the type of messaging to use 

when updating a module 
Field Entries Specific to Each Update 

NVS Instance Indicates the instance number of the object 

(e.g., boot, executive, libraries, custom routines, 
adjustable machine parameters) being updated 

MajorRevision Indicates the major revision of the instance being 

updated 

Minor Revision Indicates the minor revision of the instance being 

updated 

MaxTimeoutSeconds Indicates the number of seconds to wait for a 

response from the object being updated before a 

timeout error is issued 
StartingLocation Indicates the starting location in the memory of 

the target module where the update should 

be stored 

FUeSize Indicates the number of bytes in the file to be 

transferred to the target module 
DataFileName Indicates the name in the firmware library of the 

data file containing the data to be sent to the 

target module 

Update Reset Rag which indicates whether the target module 

should be reset at the conclusion of the update 

AutoResetOnError Flag which indicates whether the target module 
should be reset if an error occurs during 
the update 

FirstTransfer Delay Indicates the number of seconds to wait after 

receiving the UPDATE response message before 

sending the first data transfer 
Errorlnstructions Text string containing special instructions to be 

displayed on the user interface if an error 

occurs during the update 



It may be noted that the same script file can be used to 
perform multiple updates to the same target module. As 
detailed below, the firmware is comprised of multiple 
instances, and each instance (e.g., boot, ID, executive) 
constitutes a separate update. If multiple updates are 
performed, the field entries common to all updates are stated 
only once in the script file (e.g., at the beginning), whereas 
the field entries specific to each update are repeated 
(although with new field values in at least some of the fields) 
for each additional update performed. 

The other two main functional components of the system 
10 are the PLC processor module 32 and the target module 
42. The PLC processor module 32 and the target module 42 
each respectively comprise a non-volatile memory 70 and 90 
and a volatile memory 72 and 92. The non -volatile memo- 
ries 70 and 90 each respectively comprise firmware includ- 
ing boot instances 74 and 94, ID instances 76 and 96, and 
executive instances 78 and 98. In each case, the boot 
instance, the ID instance, and the executive instance collec- 
tively implement an operating system. 

As previously indicated, the boot instance 94, ID instance 
96, and executive instance 98 each constitute separate 
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updates. Thus, if each of these instances is updated, then 
three separate updates are performed (NumberUpdates«3) 
and the script file contains three sets of the update-specific 
field entries set forth in Table 1. 
5 Of course, the updates could be performed at any level of 
granularity. For example, rather than having the entire 
executive instance 98 correspond to one update, the program 
which constitutes the executive instance 98 could be broken 
down into a plurality of firmware programs each constituting 
10 their own update. Alternatively, one update could corre- 
spond to replacing the entire contents of the non-volatile 
memory 70. 

The executive portions 78 and 98 each comprise a plu- 
rality of objects which give the modules 32 and 42 their 

15 functionality. The PLC processor module 32 includes a 
production object 82, a memory object 84 and a plurality of 
other objects 86. (Note that, while the production object 82 
of the illustrated embodiment is located in the PLC proces- 
sor module 32, there is no inherent reason why this must be 

20 the case. The production object 82 could be placed in 
virtually any type of module.) 

The production object 82 performs the non-volatile 
memory update to the target module 42 based on the script 
and data files which are loaded into the RAM 72 of the PLC 

25 processor module 32. Like other objects in an object- 
oriented programming language, the production object 82 
models a real world problem (i.e., programming memory 
during production and/or in the field), and provides a plu- 
rality of services and has a plurality of attributes which 

30 define the characteristics of the production object 82 and the 
services it provides. The production object preferably has 
the following services: 

CREATE (which creates a new instance of the production 
object 82), 

35 SET ATTRIBUTE (which sets an attribute of the produc- 
tion object 82), 
START (which starts updating the target module 42 by 
causing the production object 82 to initiate communi- 
cation with the target module 42 and begin transferring 
40 the data file to the target module 42), 

GET ATTRIBUTE (which gets an attribute of the pro- 
duction object 82), and 
DELETE (which deletes an instance of the production 
45 object 82). 

Further, the production object 82 and its services preferably 
have the following attributes: 

REVISION (which identifies the revision of the produc- 
tion object 82), 

50 DATA POINTER (which points to the data file in the 
RAM 72), 

SCRIPT POINTER (which points to the script file in the 
RAM 72), 

STATUS (which indicates the status of the production 
55 object 82), and 

TIME-OUT (which defines the maximum allowable time 
for the STATUS attribute to return to idle before a 
time-out error is issued). 
Of course, the services and attributes could be renamed 
60 while still providing the same or generally similar function- 
ality. The services and attributes of the production object 82 
are discussed further with respect to FIGS. 3-4 below. 

Referring now to FIGS. 3-4, a process 100 used for 
updating the target module 42 in accordance with the present 
65 invention is illustrated. 

By way of overview, the process 100 can be broken down 
into three major parts. First, in steps 110-134, the user 
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interface 21 performs (or at least initiates) various set-up 
operations at the user interface 21 itself and at PLC proces- 
sor module 32. Included among the set-up operations is the 
transferring of the firmware revision to the production object 
82. Second, in steps 136-140, the production object 82 is 5 
invoked and the firmware revision is transferred to the target 
module 42. During this time, control is passed to the 
production object 82, which then transfers the firmware 
revision to the target module 42 in step 140 (illustrated in 
detail in FIG. 4). Finally, in steps 160-176, control is 10 
returned to the user interface 21, which then determines if 
additional updates should be performed and, if so, initiates 
the additional updates. 

More specifically, the process 100 starts at step 110 where 
various preliminary set up operations occur. For example, is 
assuming the process 100 is being used to perform updates 
in the field, the user must take PLC system 30 off line. In 
either case, the user must also select a particular script file 
from the firmware library 23 corresponding to the firmware 
revision that the user wishes to load into the target module 20 
42. If the script and data files are not already in the firmware 
library 23, the user must load them via floppy disk or via the 
network. 

Once the user selects a script file, the production object 82 
verifies the script format, displays the script file to the user, 25 
and displays the status of script format verification to the 
user. The production object 82 also verifies that the data 
file(s) contained in the script file are accessible, and displays 
the status of the data file verification to the user. 

The process 100 then proceeds to steps 120-126, where 30 
the script and data files are transferred from the PC 20 to the 
PLC processor module 32. Specifically, at step 120, the user 
interface 21 first invokes the memory object 84 to allocate 
a first memory block in the PLC processor module 32. 

The memory object 84 is responsible for managing the 35 
memory of the PLC processor module 32. As such, the 
memory object includes the services ALLOCATE, 
DEALLOCATE, WRITE and READ. Further, as discussed 
above, the services of objects in an object-oriented system 
are accessed through a message-based interface. The mes- 40 
saging occurs in two parts: a request message and a response 
message. Thus, in order to invoke the memory object 84 to 
allocate a first memory block in the PLC processor module 
32, the user interface 21 sends an ALLOCATE request 
message to the memory object 84. The parameters of the 45 
ALLOCATE request message include the size of the 
memory block requested, which in this case corresponds to 
the size of the script file. The memory object 84 then 
responds with an ALLOCATE response message, which 
confirms that the ALLOCATE request has been granted and 50 
advises the user interface 21 of the starting address of the 
first allocated memory block. 

At step 122, the script file is transferred from the PC 20 
to the PLC processor module 32 by way of the RS-232 link 
50. The script file is written into the first memory block 55 
using the WRITE service of the memory object 84. The 
status of the script file transfer is preferably displayed to the 
user. 

At step 124, the user interface 21 invokes the memory 
object 84 to allocate a second memory block in the PLC 60 
processor module 32. Again, the user interface 21 sends an 
ALLOCATE request message which indicates the size of the 
memory block requested to the memory object 84. In this 
case, the size of the second memory block corresponds to the 
total size of all of the data files for all of the updates to be 65 
performed. (For example, if the script file contains three 
updates, then the size of the memory block requested 
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corresponds to the total size of the three data files for the 
three updates in the script file. For simplicity, it will initially 
be assumed that the script file contains only one update.) 
Again, the memory object 84 then responds with an ALLO- 
CATE response message, which confirms that the ALLO- 
CATE request has been granted and advises the user inter- 
face 21 of the starting address of the second allocated 
memory block. 

At step 126, the data file is transferred from the PC 20 to 
the PLC processor module 32 by way of the RS-232 link 50, 
and written to the RAM 72 using the WRITE service of the 
memory object 84. The status of the data file transfer is 
preferably displayed to the user. 

At step 130, the user interface 21 sends a CREATE 
request message to the production object 82 to create a new 
instance of the production object 82. The CREATE and 
DELETE services are used for creating and deleting an 
instance of the production object. Although the production 
object 82 is continuously resident on the PLC processor 
module 32, a new instance of the production object is 
created each time the production object 82 is used. 

In essence, the creation of a new instance of the produc- 
tion object 82 simply means that resources of the PLC 
processor module 32 are allocated to the production object 
82. Primarily, the allocated resources are memory resources 
of the PLC processor module 32. The creation and deletion 
of new instances of the production object 82 in this manner 
minimizes the resources occupied by the production object 
82 when (as is normally the case) the production object 82 
is not in use. 

At step 132, the user interface 21 sends a SET 
ATTRIBUTE request message to the production object 82 in 
order to set the SCRIPT POINTER attribute and the DATA 
POINTER attribute. The SCRIPT POINTER and the DATA 
POINTER attributes are set to the starting addresses of the 
first and second memory blocks, respectively. 

Notably, rather than pointing to the RAM 72, the DATA 
POINTER could instead point to the location of the PLC 
processor module's own firmware in the non-volatile 
memory 70. This could be done if the PLC processor module 
32 has itself been updated and the user simply wishes to 
update one or more other PLC processor/target modules in 
the same manner. Advantageously, the ability to "clone" the 
PLC processor module 32 in this manner avoids the need to 
transfer a data file to the RAM 72 at step 126 (the most time 
consuming part of the process 100). Of course, a script file 
is still needed when cloning occurs, because the production 
object 82 still needs to know how the firmware revision 
should be performed. 

At step 134, the user interface 21 initiates a timer which 
allows the update to be aborted if a fault occurs causing a 
maximum allowable update time to be exceeded. To estab- 
lish the timer, the user interface 21 sends a GET 
ATTRIBUTE request message to the production object 82 in 
order to request the TIME-OUT attribute at step 134, and 
initiates the timer based on the TIME-OUT attribute. As 
noted above, the TIME-OUT attribute defines the maximum 
allowable time for the STATUS attribute to return to idle 
before a time-out error occurs. 

At step 136, the user interface 21 sends a START request 
message to the production object 82. Upon reception of the 
START request message, the production object reads the 
script file at the SCRIPT POINTER location, and then 
interprets the script to determine how to perform the update. 
The START request message also causes the production 
object 82 to initiate communication with the target module 
42 and begin transferring the firmware update to the target 
module 42. 
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At step 140, the production object 82 transfers the firm- As the iterations of steps 150-152 occur, the user interface 

ware update to the target module 42. Step 140 is illustrated 21 periodically (e.g., once every 2.5 seconds) sends GET 

in greater detail in FIG. 4. Referring now to FIG. 4, the ATTRIBUTE request messages to the production object 82 

sequence of messages between the production object 82 to poll the status of the production object 82. The GET 

(left-hand side) the target module 42 (right-hand side) is 5 ATTRIBUTE request message is used to check the status of 

illustrated. the update until one of the following status reports is 

At step 142, the production object 82 transmits a GET received: "completed", "error", or "timed-out". 

ATTRIBUTE request message to a device object 93 of the At step 156, after the data is successfully and completely 

target module 42 (see FIG. 2), and at step 144 the device transferred, and assuming the UpdateReset flag is set in the 

object 93 responds with a GET ATTRIBUTE response 10 script file, the production object 82 transmits a RESET 

message containing the requested information. The device request message in order to reset the target module 42 and 

object 93 has attributes which store identification informa- the "completed" status report is sent to the user interface 21. 

lion regarding the target module 42 (e.g., serial number, If there are multiple target modules, then the production 

hardware revision, catalog number, software revision, and/ object 82 proceeds with transferring the first update to the 

or other information). Thus, the GET ATTRIBUTE service is other target modules. If a particular target module update is 

of the device object 93 is used by the production object 82 unsuccessful, the production object 82 ceases communica- 

to access the identification information and verify that the tion with that target module and attempts to update other 

correct type of module is being updated. (The GET modules until an update to the last slot in the backplane 54 

ATTRI BUT E service of the device object 93 is similar to the has been attempted. Advantageously, it is not necessary for 

GET ATTRIBUTE service of the production object 82, 20 the production object 82 to perform another download over 

except that it is used to get the attributes of the device object the (slow) RS-232 link 50 each time the first update is 

93 and not the production object 82.) transferred to another module over the (high-speed) back- 

At step 146, the production object 82 transmits an plane 54. 
UPDATE request message to an NVS (non-volatile storage) If there are multiple target modules and multiple updates 
object 95 of the target module 42 (see FIG. 2B). The NVS 25 in the script file, then each update is first transferred to each 
object 95 handles performing updates to the non-volatile of the other target modules before the production object 82 
memory 90. The UPDATE service is one of the services proceeds to the next update. Thus, the production object 82 
offered by the NVS object 95, and is used simply to inform first transfers the first update to all of the target modules, 
the NVS object 95 that an update is requested. (As detailed then transfers the second update to all of the target modules, 
below, the NVS object 95 also offers a TRANSFER service 30 and so on. This process continues automatically until all of 
which is used to transfer data to the target module 42.) The the updates have been transferred to all of the target mod- 
parameters of the UPDATE request message include the ules. 

starting address and size of the update. As noted above, a RESET request message is sent to the 

At step 148, the target module 42 responds to the target module after each update is performed (assuming the 

UPDATE request message with an UPDATE response mes- 35 UpdateReset flag is set). Since it takes a module about 10 

sage. The parameters of the UPDATE response message seconds to reset, the fact that the production object 82 

include the maximum allowable size for individual transfers transfers each update to all of the target modules before 

of data. The transfer size must be less than or equal to the proceeding to the next update gives the target modules time 

connection size defined by the backplane 54 (e.g., 128 to reset after an update is complete, 

bytes). At this time, the target module 42 stops all of its other 40 After all of the updates have been performed to all of the 

activities and does not initiate any new activities until the modules in the backplane 54, the user interface permits the 

update is complete. user to perform the same update to more modules of the 

At step 150, the production object 82 receives the same type as those that were just updated, to perform a 

UPDATE response message and sends a TRANSFER different update to different modules than the type just 

request message. The transfer service of the NVS object 95 45 updated, or to not perform any more updates, 

is used to transfer data (i.e., the firmware update itself) to the Thus, at step 160, the user interface prompts the user 

target module 42. The parameters of the TRANSFER whether the user wishes to perform the same update to more 

request message are a transfer number and the data. Initially, modules of the same type. If the user answers "YES" at step 

the transfer number represents an onset from a base address 160, then at step 162 the user inserts the additional target 

in the volatile memory 92 of the target module 42. Then, 50 modules into the backplane 54 or, alternatively, removes the 

with each repetition of step 150, the transfer number is PLC processor module 32 from its current backplane and 

incremented by the number of bytes transferred. places it into a new backplane which is already loaded with 

At step 152, the target module 42 responds to the TRANS- the additional target modules. The process 100 then returns 

FER request message with a TRANSFER response message. directly to 136, where another START request message is 

The parameters of the TRANSFER response message are 55 transmitted to the production object 82, Notably, steps 

the last transfer number received (which is the same param- 110-134 are skipped, since the production object 82 still has 

eter value as in the TRANSFER request message) and the the required script and data files and is completely set up to 

status (which indicates the success or failure of the transfer). update the additional modules. This is highly advantageous 

Steps 150 and 152 are repeated until the update is com- because, as previously noted, transferring the data file to the 

plete. For example, if the size of the update is 600 kilobytes 60 PLC processor module 32 (at skipped step 126) is the most 

(FileSize=600 kilobytes=6 14400 bytes), and the transfer time consuming part of the process 100. 

size is 128 bytes, then approximately 4800 iterations If the user answers "NO" at step 160, then at step 164 the 

(614400+128-4800) of steps 150-152 occur. (Note that, if user interface 21 sends a DEALLOCATE request message to 

multiple updates to the same target module are performed, the memory object 84 to deallocate the first and second 

then multiple iterations of the steps 146-156 occur, includ- 65 memory blocks. The fact that the user does not wish to 

ing multiple iterations of steps 150-152 within each iteration perform the same update to more modules of the same type 

of steps 146-156.) implies that the previously downloaded script and data files 
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are no longer needed, and thus that the memory in which the decrypted serial number that was downloaded with the 

they are stored may be deallocated. firmware revision with the serial number obtained from the 

At step 170, the user interface prompts the user whether device object of the target module. (Of course, instead of 

the user wishes to perform a different update. Strictly decrypting the downloaded serial number, the production 

speaking, any update which requires different script and data 5 object 82 could encrypt the serial number received from the 

files would constitute a different update. Generally, however, device object and then compare the two encrypted serial 

the different update would involve a different type of mod- numbers.) The update is then performed only if there is a 

ule. Thus, at step 172 the user inserts additional target "match." 

modules into the backplane 54 or, alternatively, removes the If updates to multiple modules are performed, then the 

PLC processor module 32 from its current backplane and 10 serial numbers of each of the target modules are encrypted 

places it into a new backplane which is already loaded with by the encryption program 210. The encrypted list of serial 

the additional target modules. Then, the process 100 starts numbers is then downloaded in the security file to the 

over at step 110 and proceeds as previously described, production object 82, where the list is decrypted. When it is 

except that a new instance of the production object 82 need time to update a particular target module, the production 

not be created in step 130 (since the previous instance of the is object 82 then compares the serial number of the particular 

production object 82 was never deleted). target module with the decrypted list of serial numbers. 

If the user answers "NO" at both steps 160 and 170, then Again, the update is performed only if there is a "match." 

no more updates are performed. Accordingly, at step 174, a Thus, the encryption/decryption system of FIGS. 5A-5C 

DELETE request message is sent to the production object provides a way of preventing a customer from transferring 

82, which deletes the instance of the production object 82 20 a firmware update to more than the approved number of 

and deallocates the resources that were allocated to the target modules. 

instance of the production object 82. The process 100 is thus Advantageously, the preferred embodiment of the present 

complete. invention provides a rapid way of programming modules 

Referring now to FIGS. 5A-5C, an encryption/decryption having non -volatile memory. Unlike prior art systems, the 

system 200 usable in conjunction with the non-volatile 25 programming tool is in the form of an embedded object and 

memory programming system 10 and process 100 described is located internally and not externally to the programmable 

in FIGS. 1-4. The purpose of the encryption/decryption controller system. As a result, it is possible to transfer the 

system is to prevent unauthorized proliferation of propri- firmware program to the production object just once (e.g., 

etary firmware when field updates are performed. over a serial link), and then the production object can 

The system 200 comprises an encryption program 210 30 transfer the firmware program to a virtually unlimited num- 

and a decryption program 220. The encryption program 210 ber of target modules over a high -speed network connection, 

is in the possession of the firmware producer, and resides for Thus, it is no longer necessary to have a one-to-one corre- 

example on a personal computer. The decryption program spondence between the number of modules updated and the 

220 is a part of the production object 82 and resides on the number of downloads performed over a slow-speed com- 

PLC processor module 32. The encryption program 210 and 35 munication link, and the amount of time required to program 

the decryption program 220 preferably utilize the same key a plurality of modules is drastically reduced. 

215 and preferably perform the inverse operations of each Further, the preferred embodiment of the present inven- 

other (although a more complicated encryption/decryption tion is usable both during production and in the field. It is not 

scheme could be used). necessary to have two different systems for programming 

When a customer wishes to have the firmware of a target 40 modules depending on when the programming takes place, 

module updated, the customer provides the firmware pro- Thus, the preferred embodiment of the present invention is 

ducer with the serial number of the target module. The serial able to drastically reduce programming time without requir- 

number is unique to the target module and distinguishes the ing different systems for programming during production 

target module from every other individual module in the and in the field. 

entire PLC product line. The firmware producer then uses 45 Moreover, the preferred embodiment of the present inven- 
the encryption program 210 to encrypt the "approved" serial tion minimizes the downtime of modules when updating 
number of the target module based on the encryption key occurs, even when only a single module is updated. The 
215. The encryption program 210 generates an encrypted target module does not need to be plugged into the back- 
serial number which is then downloaded to the PLC pro- plane until after the firmware program is transferred to an 
cessor module 32 in the form of a security file. The security 50 intermediate module (e.g., in the illustrated example, the 
file is analogous to the script and data files except that it is PLC processor module 32) over the serial link. During this 
used for downloading one or more encrypted serial numbers transfer, the target module can still be used for controlling 
to the PLC processor module 32, The security file is down- industrial processes. Thus, the only truly required downtime 
loaded to the PLC processor module 32 in generally the is the nominal amount of time that it lakes to plug the target 
same manner as the script and data files. Thus, in the process 55 module into the backplane and transfer the firmware update 
100, there is also a step in which a third memory block is to the target module over the backplane, which is preferably 
allocated in the PLC processor module 32 for the security a high seed backplane. 

file, and the production object also includes a SECURITY Finally, the preferred embodiment of the present inven- 

POINTER attribute. tion provides a single tool which can be used to program a 

In the field, the firmware revision (including the security 60 plurality of different modules, regardless of the types of 

file) is downloaded to the production object 82 on the PLC communication ports disposed on the fronts of the modules, 

processor module 32. The encrypted serial number is The firmware update can always be first communicated to a 

decrypted using the decryption program 220. Concurrently, single type of module, and then transferred to any type of 

the production object 82 accesses the device object of the target module so long as the target module is disposed on the 

target module using the GET ATTRIBUTE service (as 65 common backplane. Therefore, it is no longer necessary to 

previously described) in order to obtain the serial number of have a separate programming tool for each module having a 

the target module. The production object 82 then compares different type of communication port. 
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Many other changes and modifications may be made to 
the present invention without departing from the spirit 
thereof. The scope of these and other changes will become 
apparent from the appended claims. 

What is claimed is: 

1. A production object for an object-oriented program- 
ming language, said production object being disposed in a 
first module, and said production object comprising: 

a plurality of services and a plurality of attributes which 
are adapted for transferring an executable program 
from the first module to a second module over a 
common network; 

wherein said plurality of services include a first service 
that is capable of creating a new instance of said 
production object to transfer the executable program 
from the first module to the second module; and 

wherein said plurality of services include a second service 
that is capable of setting at least one of the plurality of 
attributes, said at least one attribute defining a param- 
eter pertaining to the transfer of the executable program 
from the first module to the second module. 

2. The production object according to claim 1, wherein 
said production object is further adapted for transferring the 
program from the first module to a plurality of additional 
modules over the common network. 

3. The production object according to claim 1, wherein the 
program is contained in a data file, wherein a script file 
defines parameters for transferring the program to the sec- 
ond module, and wherein said plurality of attributes includes 

a script pointer attribute, said script pointer attribute 
pointing to a first location in a memory of the first 
module where the script file is stored; and 

a data pointer attribute, said data pointer attribute pointing 
to a second location in the memory of the first module 
where the data file is stored. 

4. The production object according to claim 3, wherein 
said plurality of services includes 

a delete service, said delete service being adapted for 

deleting said new instance of said production object 

after the program is transferred; 
and wherein resources of the first module are allocated 

and deallocated when said new instance is created and 

deleted, respectively. 

5. The Production Object according to claim 1, wherein 
said executable program implements at least a portion of an 
operating system for said second module. 

6. The Production Object according to claim 1, wherein 
said common network comprises a common backplane of 
said first and second modules. 

7. The production object according to claim 1, wherein 
said executable program implements at least a portion of an 
operating system for said second module. 

8. A method of transferring a firmware program to a 
plurality of target modules in a programmable controller 
system, said programmable controller system being pro- 
grammable with an object-oriented programming language, 
the method comprising the steps of: 

A. transferring said firmware program from a user inter- 
face to a first module, said first module being a pro- 
grammable controller module; and 

B. transferring said firmware program from said first 
module to said plurality of target modules over a 
common backplane, said plurality of target modules 
being programmable controller modules, said plurality 
of target modules and said first module being com- 
monly disposed in said common backplane, said trans- 
ferring step (B) including the steps of 



47,168 Bl 

14 

1. invoking a production object which is disposed in 
said first module, said production object being part 
of said object-oriented programming language, and 
said production object having a plurality of services 

5 and a plurality of attributes which are adapted for 

transferring said firmware program from said first 
module to said plurality of target modules, and 

2. using said production object to transfer said firmware 
program from said first module to said plurality of 

10 target modules. 

9. The method according to claim 8, further comprising 
the steps of 

1. removing said first module from said common back- 
plane; then 

15 2. placing said first module in a different common back- 
plane having a different plurality of target modules 
disposed therein, said different plurality of target mod- 
ules being programmable controller modules; and then 

20 3. transferring said firmware program from said first 
module to said different plurality of target modules 
over said different common backplane, said transfer- 
ring step (3) being performed by said production 
object. 

25 10. The method according to claim 8, further comprising 
the steps of 

1. removing said plurality of target modules from said 
common backplane; then 

2. placing a different plurality of target modules in said 
30 common backplane, said different plurality of target 

modules being programmable controller modules; and 
then 

3. transferring said firmware program from said first 
module to said different plurality of target modules 

35 over said common backplane, said transferring step (3) 
being performed by said production object. 

11. The method according to claim 8, wherein said first 
module is a programmable controller processor module. 

12. The method according to claim 8, wherein said 
40 firmware program is contained in a data file, wherein a script 

file defines parameters for transferring said firmware 
program, and further comprising the steps of 

setting a script pointer attribute, said script pointer 
attribute pointing to a first location in a memory of said 
45 first module where said script file is stored; and 

setting a data pointer attribute, said data pointer attribute 
pointing to a second location in said memory of said 
first module where said data file is stored. 
5Q 13. The method according to claim 8, wherein said 
firmware program is a firmware program for said first 
module, and further comprising the steps of 

setting a script pointer attribute, said script pointer 
attribute pointing to a first location in a memory of said 
55 first module where a script file is stored, said script file 
defining parameters for transferring said firmware pro- 
gram; 

cloning said first module, said cloning step including the 
step of setting a data pointer attribute, said data pointer 
60 attribute pointing to a second location in said memory 
of said first module where said firmware program is 
stored. 

14, A method of transferring a firmware program to a 
plurality of target modules, the method comprising the steps 
65 of: 

A. providing a programmable controller system compris- 
ing a first module and said plurality of target modules, 
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said programmable controller system being program- 
mable with an object-oriented programming language, 
and said first module and said plurality of target mod- 
ules being commonly disposed in a common back- 
plane; 

B. sending a first allocate request message to a memory 
object in said first module, said memory object having 
a plurality of services and a plurality of attributes which 
are adapted for managing memory of said first module; 

C. allocating a first memory block in said memory of said 
first module, said allocating step (C) being performed 
by said memory object in response to said sending step 
(B); 

D. transferring a script file from a user interface to said 
first memory block, said script file defining parameters 
for transferring said firmware program to said plurality 
of target modules; 

E. sending a second allocate request message to said 
memory object in said first module; 

F. allocating a second memory block in said memory of 
said first module, said allocating step (F) being per- 
formed by said memory object in response to said 
sending step (E); 

G. transferring a data file from said user interface to said 
second memory block, said data file containing said 
firmware program; 

H. sending a create request message to a production 
object, said production object having a plurality of 
services and a plurality of attributes which are adapted 
for transferring said firmware program from said first 
module to said plurality of target modules, said pro- 
duction object being disposed in said first module, said 
create request message causing a new instance of said 
production object to be created for transferring said 
firmware program to said plurality of target modules; 

I. setting a script pointer attribute, said script pointer 
attribute pointing to said first memory block, and said 
script pointer attribute being one of said plurality of 
attributes of said production object; 

J. setting a data pointer attribute, said data pointer 
attribute pointing to said second memory block, and 
said data pointer attribute being one of said plurality of 
attributes of said production object; 

K. invoking said production object; and 

L. transferring said firmware program from said first 
module to said plurality of target modules over said 
common backplane, and said transferring step (L) 
being performed by said production object. 

15. The method according to claim 14, further comprising 
the steps of 

encrypting information which identifies said plurality of 
target modules, 

transferring said encryped information to said first 
module, and 

decrypting said encrypted information at said first 
module, and 



wherein said transferring step (L) is performed only after 
verifying that said information matches information 
previously stored in each of said plurality of target 
modules. 

5 16. The method according to claim 15, further comprising 
the steps of: 

A. sending a third allocate request message to said 
memory object in said first module; 
10 B. allocating a third memory block in said memory of said 
first module, said allocating step (B) being performed 
by said memory object in response to said sending step 
(A); 

C. transferring a security file from said user interface to 
15 said third memory block, said security file containing 

said encrypted information; and 

D. setting a security pointer attribute, said security pointer 
attribute pointing to said third memory block, and said 

20 security pointer attribute being one of said plurality of 
attributes of said production object. 
17. A method of transferring a firmware program to a 
plurality of target modules, the method comprising the steps 



of: 
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A. providing a programmable controller system compris- 
ing a first module and said plurality of target modules, 
said programmable controller system being program- 
mable with an object-oriented programming language, 
and said first module and said plurality of target mod- 
ules being commonly disposed in a common back- 
plane; 

B. sending an allocate request message to a memory 
object in said first module, said memory object having 
a plurality of services and a plurality of attributes which 
are adapted for managing memory of said first module; 

C. allocating a memory block in said memory of said first 
module, said allocating step (C) being performed by 
said memory object in response to said sending step 

(B); 

D. transferring said firmware program from a user inter- 
face to said memory block; 

E. sending a create request message to a production 
object, said production object having a plurality of 
services and a plurality of attributes which are adapted 
for transferring said firmware program from said first 
module to said plurality of target modules, said pro- 
duction object being disposed in said first module, said 
create request message causing a new instance of said 
production object to be created for transferring said 
firmware program to said plurality of target modules; 

F. invoking said production object; and 

G. transferring said firmware program from said first 
module to said plurality of target modules over said 
common backplane, and said transferring step (G) 
being performed by said production object. 
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